home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
misc
/
merit
/
noop
/
tutorial
/
idrp.tut
< prev
next >
Wrap
Text File
|
1992-01-20
|
44KB
|
885 lines
IDRP Tutorial
By Susan Hares (MERIT)
Introduction
------------
Out of the fertile ground of the Internet and the traditional
ANSI subcommittees has sprung an OSI Inter-Domain Routing
Protocol (IDRP). This protocol is officially called
"Information Processing Systems - Telecommunications and
Information Exchange between Systems - Protocol for
Exchange of Inter-Domain Routeing Information among
Intermediate Systems to Support Forwarding of ISO
8473 PDUs (CD 10747)".
This paper provides an overview of the IDRP protocol in terms of
its architecture and features. No attempt has been made to
describe the format of packets or state machines. These details
are better left to the protocol document. Charlie Kunzinger
(IBM), the editor of the ISO IDRP document, has kept this
document readable, and deserves a lot of thanks for his efforts.
IDRP has progressed along the standards track to Committee Draft
(CD) ballot. CD Ballot is the second stage in the ISO standards
process. This stage is similar to "Proposed Internet Standard"
status in the IP Internet world. The current protocol
description is firm foundation for implementation but, like all
standards at the Committee Draft level, IDRP is still open to
possible technical changes.
Merit demonstrated a prototype implementation of the IDRP during
INTEROP 91. Experience with the prototype has been fed back into
the IDRP specification. For additional information about the
IDRP prototype, please contact Merit (email address:nsfnet-info
@merit.edu).
Special thanks go to Charlie Kunzinger (IBM), the editor of IDRP,
whose ten pages of overheads were turned into this document.
Thanks are also due to Dave Katz (Merit) and Yakov Rekhter (IBM)
who reviewed this document extensively.
Architectural Overview
======================
OSI Routing Environment
-------------------------
The OSI routing environment is described in ISO TR 9575 [1] as a
set of interconnected Routing Domains (RDs). RDs are groups of
hosts and routers that operate according to the same routing plan
and are administered by a single authority. Routing domains
interact with each other in a "mutually suspicious manner" [1]
due to their mutual independence and autonomy. Routing domains
may each have their own view of what constitutes an optimal
route. The OSI routing environment does not require that all
routing domains have homogenous criteria (policy) about how to
select an optimal route.
In many ways a routing domain is like an Autonomous System in the
1
IP Internet [2]. Routing information passed within a routing
domain (Intra-Domain) is trusted. Routing information passed
between domains (Inter-Domain) may not be trusted. IDRP provides
a means to communicate routing information and to calculate
routes between routing domains. IDRP does not require that all
routing domains have homogeneous criteria (policy) for route
selection[3].
Routing knowledge needs to be spread throughout an internet in
some ubiquitous manner if packets are going to reach their
destinations. However, the independent and autonomous status of
routing domains within an internet work against providing
homogeneous routing information. In this environment, some
routing domains (such as NSFNET) need to carry traffic on behalf
of other routing domains. Routing domains that carry traffic on
the behalf of other routing domains are known as Transit Routing
Domains (regional networks and backbone networks, for example).
Since a routing domain has only a finite amount of resources, it
must control on how these resources are used. For example, NSF
does not want to subsidize XYZ Corporation by allowing the
commercial traffic from XYZ Corporation to go across NSFNET. To
control what traffic passes through NSFNET, NSFNET controls what
routing information it accepts and transmits. By using this
control, NSFNET does not carry the commercial traffic for XYZ
corporation.
In an atmosphere, in which each routing domain needs to control
the traffic passed through it by controlling the dissemination of
routing information, one RD may filter the routing information
it receives from another RD. By filtering the routes, a routing
domain keeps only the routing information needed to do its job.
A routing domain may also filter what it sends to other RDs so
that only certain pathways are used. In addition, configurations
are set up to authenticate the remote peer sending the
information. This filtering and authentication creates a
"firewall" to keep each routing domain independent of other
routing domains.
Routing domains whose policies do not permit them to carry
transit traffic are known as End Routing Domains. End Routing
Domains may be further subdivided into those connected to a
single adjacent RD (Stub) and those connected to multiple
adjacent RDs (multi-homed). In figure 1, C is a transit routing
domain and B is a multi-homed routing domain. Routing domain A
is a stub routing domain. Routing domain A is adjacent to
routing domain C.
---------- ------------ ------------
| RD A |--------------| RD C | | RD D |
| (stub) | | transit |------------| transit |
----------- ------------ -------------
| |
\ /
\ /
\ /
----------------
| RD B |
| multi-homed |
---------------
2
Figure 1 - Routing Domains
Inter-Domain Routing Goals
---------------------------
IDRP is designed to provide for the deterministic selection of
paths through the OSI environment (internet) taken by network
layer packets. Included in the design criteria for IDRP are the
ability to:
- scale well to a growing internet, and
- allow transit routing domains to transit
traffic.
Additionally, IDRP assumes that the OSI environment (internet)
may face multiple cuts to the topology of the network. Therefore
IDRP provides routing that adapts to the topological changes (at
the Inter-Domain level).
When a protocol scales well, it will make efficient use of
network bandwidth and the processing and memory within routers.
IDRP was designed to fit into the OSI stack without affecting the
existing network layer protocols. These protocols are:
CLNP - Connectionless Network Layer Protocol (ISO 8473) [3]
ES-IS - End System to Intermediate System routeing exchange
protocol (ISO 9452) [4]
IS-IS - Intermediate System to Intermediate System
Intra-Domain Routeing protocol (ISO 10589) [5]
IDRP does not require either ES-IS or IS-IS in order to operate
properly. The only requirement placed on the intra-domain
routing environment is the presence of stable paths between
border routers in the same RD participating in IDRP (for the
forwarding of transit traffic) and the presence of stable paths
to and from end systems within the routing domain (for the
forwarding of traffic originating or terminating within the local
RD). IDRP was not designed to provide user data security, to
adapt routes based on traffic load, or to repair partitions of
routing domains.
Multiple Qualities of Service
-----------------------------
The OSI connectionless network layer protocol (ISO 8473) allows a
network packet to request several qualities of service (QOS).
This QOS is similar to types of service (TOS) in IP. These QOS
values allow a packet to be "colored". IDRP supports the
calculation of separate paths for each of these different
qualities of service by means of Distinguishing Attributes [5],
thus allowing paths or routes to be "colored".
When an ISO 8473 packet comes into a router, the router will
check to see if the packet has been "colored" by QOS. If so,
the router looks up the destination address in the appropriate
3
QOS's routing table. The IDRP protocol specifies a mapping
between the QOS values (packet's "color") and an IDRP
inter-domain pathway (the route's "color"). If no QOS value has
been set, the default routing table is used.
Most of the Internet will probably start out having only a
"default" QOS (or colorless pathway). Packets without any QOS
(colorless packets) may be able to travel much further than
"colored" packets. If a pathway of the right QOS (color) is not
available, the packet is dropped.
The CLNP QOS function or an IDRP QOS pathway does not have to be
supported by each system in the pathway. However, each system
must correctly handle a packet with a QOS value set. For
example, suppose a particularly miserly end system wanted to send
a packet along pathways which had minimal costs. He would set
the "Expense" bit (perhaps like a green color) in the network
layer packet and shove the packet out the door to a router. If
IS-IS is used within a routing domain, the local routing domain
would pass the packet on a low expense route until it hit a
router on the border of the routing domain. This border router
would check in its routing tables to find a route which had low
expense. If it found one, the miserly end systems's packet would
speed along low cost routes. If a route was not found, the
packet would be discarded and an Error PDU would be passed back
to the miserly end system. Given that our miserly end system did
not want to spend lots of money reaching the destination, this
behavior makes the end system happy. If the miserly end system
must spend the money to send this packet, it can switch to a
route with no QOS set (colorless) when it receives the ERROR PDU.
(Figure 2 - Miserly Packet example goes here. Note
figure two is only available in the postscript version.
The figure is available for anonymous ftp from merit.edu.
The file is located in /pub/iso/noop/tutorial/idrp.f02.ps)
Scope of QOS
-------------
The "color" of a packet (QOS) or route (Distinguishing Attribute)
has a scope. The scope may either be specific to:
- a source address
(a route may have scope for a group of source addresses),
- a destination address
(a route may have scope for a group of destination
addresses), or
- a globally unique QOS such as the Expense flag.
Two types of "color" for the packet or route (QOS and
Distinguishing Attributes) deal with source addresses: Source
Specific QOS and Source Specific Security QOS. Two types of
"color" deal with destination addresses: Destination Specific QOS
and Destination Specific Security QOS.
To indicate a globally unique QOS value, a value is set in the
header of a CLNP (ISO 8473) packet in an option field. For
example, the packet from our miserly end system would have a bit
set that indicates "Expense" QOS. The "Expense" Distinguishing
Attribute which IDRP maps to the "Expense" QOS has a value which
4
indicates how expensive each route is. However, the meaning of
that "Expense QOS" value may be valid only within an RD or a set
of RDs.
Global availability or agreement on the colors of "packets" or
routes will probably take a great deal of coordination in the
Inter-Domain realm. Today's Internet is built on such
coordination between networks. The current policies on how
routes are passed in the Internet are implemented in router
configurations in lots of networks.
For the scope of a "color" or a packet (QOS) or a route
(Distinguishing Attribute) to truly be global, many countries may
have to agree on the exact syntax and meaning of a "color". For
example, NSF currently limits any traffic passing across the
NSFNET to being non-commercial and in support of research and
education. This type of policy restriction may be illogical
within Japan or Australia. If our miserly packet was from a
University, it could find a "golden" pathway that was the
research pathway through the US. But when it hit the US border,
the definition of what this "golden" pathway means may simply not
apply to Canada or Japan or Australia or imply something
different within those countries.
Protocol Overview
==================
A router that participates in inter-domain routing (and thus runs
the IDRP protocol) is known as a Border Intermediate System
(BIS). A routing domain may contain one or more BISs. A BIS
uses policy to select among the routes it receives. In order for
the IDRP protocol to work, all the BISs within an RD must have a
reliable and consistent picture of how to route packets. To
minimize the network bandwidth and processing power used by IDRP,
IDRP must help control the amount of information passed. The next
sections stroll through the features provided by the IDRP
protocol.
Architectural Place of IDRP
----------------------------
IDRP is part of the suite of routing protocols for in the OSI
Network Layer, and runs over the OSI Connectionless Network Layer
Protocol (CLNP ISO 8473). IDRP describes how PDUs are exchanged
between BISs, how routes are constructed, and how protocol errors
are handled, but the choice of how routes are selected is left to
the local BIS's policy. BIS PDUs are passed between BISs within
a domain and between BISs in different routing domains.
IDRP is a Path Vector Method Protocol
-------------------------------
IDRP is a "path vector" protocol, which is neither a distance
vector nor a link state protocol. The distance metric of a
distance vector protocol is not required. Unlike a link state
protocol, the full topology and explicit link status are not
distributed. In a "path vector" protocol, the routes distributed
contain a complete path to the source of the route. Such a
protocol provides the following:
5
- a vector of path attributes,
- one route to destination for each QOS value,
- excellent information hiding/abstraction and
- provides for hop-by-hop routing.
Inclusion of path information allows more rapid convergence than
classic distance vector protocols and eliminates the "count to
infinity" problem.
IDRP Information Flow
----------------------
IDRP operates between pairs of BISs as shown in figure 3.
Similar to the BGP protocol in the IP Internet, IDRP is used
between BISs within the same routing domain so that the entire RD
has a consistent picture of inter-domain routing.
-------- ---------
| RD A | | RD C |
| BIS|\ ----------- /|BIS |
| BIS | \ | RD B | / ----------
--------- ---------|BIS BIS|---
| /|BIS BIS|\ -----------
| | ----------- \ | RD E |
--------- | \---|BIS |
| BIS BIS|----------|-------------------| |
| RD D | | -----------
| BIS BIS|\ --------
---------- \ -----| BIS |
| | RD G |
| --------
-----------
| BIS |
| RD F |
-----------
Figure 3 - Routing Domains connected by BISs
IDRP allows each BIS to control routing information passed on to
other BISs. Only routes which satisfy the local policy of a BIS
and have been selected to be to be used will be passed on to the
next BIS.
IDRP exchanges routing information between BISs within a domain
and between adjacent BISs in adjacent routing domains. Since
IDRP routing updates are incremental, routing traffic between
BISs are minimized. The heaviest flow of traffic comes when a
BIS first becomes operational. The BIS must establish a
connection to other BISs in its RD and adjacent RDs. Routing
information must be sent from the adjacent BISs to this new BIS.
A BIS's route re-calculation is partial and event driven (only
newly arrived routes need to be evaluated). The events which
cause route re-calculation are:
- a BIS receives an incremental routing update with new routes,
- a BIS neighbor goes down, or
- a BIS neighbor comes up.
6
Loop Suppression in IDRP
-------------------------
The richly interconnected Internet topology provides the
opportunity to construct paths that form loops. However, IDRP
will never construct looping paths because it keeps track of all
RDs traversed by a route. If a BIS sees its own RD in a route
advertised by a BIS in another RD, it will ignore that route.
Routing Domain Identifiers
--------------------------
IDRP uses a Routing Domain Identifier (RDI) to uniquely identify
a Routing Domain. The Routing Domain Identifier is taken from
the same address space as the Network Service Access Point (NSAP)
addresses. RDIs are drawn from the NSAP address space solely to
simplify administration; no relationship should be inferred
between the value of an RDI and the NSAP addresses resident
within the RD.
IDRP Path Attributes
---------------------
Like BGP, IDRP defines a pathway as a pairing between a
destination and the attributes of that path to the destination.
A destination in IDRP is described by Network Layer Reachability
Information (NLRI). NLRI contains groups of NSAP addresses
described by NSAP prefixes. IDRP describes pathways through the
morass of routing domains as ordered sequences of RDIs. For
example, the pathway in Figure 3 between A and E could be A,B,E.
In IDRP, the attributes of a path to a destination describe the
characteristics of the path. Of these attributes, some are
"Distinguishing attributes" and color the routes. Figure 4
shows which attributes can be listed together on a pathway.
Like your mother when she gave you choices of vegetables, you can
choose one from Group A, one from Group B and one from Group C.
Unlike your mother, you also have the choice of "none", which is
called "default" routing (no vegetables).
Figure 4 - Possible Groups of Distinguished attributes
Group A Group B Group C
-------------- ---------- -----------------
-Transit Delay -Priority -Source Sensitive
-Residual Error Security
-Expense -Destination
-Capacity Sensitive
-Source Sensitive Security
QOS
-Destination
Sensitive QOS
Information Bases
-----------------
For each unique combination of distinguishing attributes and
destinations, there is local policy that affects the router.
IDRP policy is akin to BGP policy. It is policy that is set by a
routing domain administrator for a routing domain and expressed
7
in local configuration files on each node. The functioning of
the "global" internet policy is the combination of all these
"local" policies.
Each BIS builds a Routing Information Base (RIB) based on routing
information received from other BISs and from within the local
RD. The RIB represents the set of routes that has been selected
for use by the BIS.
Each remote BIS neighbor sends a BIS its RIB for each unique set
of distinguishing attributes. For example, if a BIS supports an
expense attribute (for our miserly network user) and a route with
default QOS, a Routing Information Base will be sent for
expense QOS and for default QOS. This routing information
contains only the active routes selected by the neighbor.
The local BIS, upon receiving this information, uses local policy
to select the routes, and updates its RIB. From the RIB the BIS
generates a Forwarding Information Base (FIB). The FIB
effectively contains a set of destinations and next hop BISs for
each destination.
Upon the loss of a BIS neighbor, the local BIS will re-run the
route selection function. The local BIS will use local policy to
select among the routes from the remaining neighbors, update its
RIB, and generate a new FIB.
Routing Domain Confederations
-----------------------------
A Routing Domain Confederation (RDC) is a group of routing
domains that join together in such a way that they appear to be a
single routing domain as viewed from outside the RDC. The only
common policy that must be supported among the members of the RDC
is that all routes between members of the RDC must lie entirely
within the RDC. RDCs provide a powerful mechanism for reducing
the complexity of routing information, since the details of the
internal topology of the RDC are hidden from those domains
outside the RDC. In addition, the size of the RD path
information carried by IDRP will be reduced. RDCs can overlap
and/or be nested. Figure 5 shows 6 RD organized into 3 RDCs.
RDCs A and B overlap. RDC C is nested inside of RDC B.
Routing Domain Confederations - Figure 5
6 RDs, organized into 3 Routing Confederations
-----------------|
| RDC A -------|-----------------|
| | RDC B ------------ |
| | |RDC C | |
| RD1--|---RD4----|-------RD6| |
| / | | / \ | / | |
| | | | | \ | / | |
--|---|---| | ----RD5 | |
RD2 RD3-|-| |----------| |
|-------------------------
How IDRP provides Scaling
8
--------------------------
IDRP provides good scaling by a variety of mechanisms. Three
types of information can be abstracted or hidden: Network
reachability information, topology information, and transit
policies. Topology information is expressed in terms of RD
pathways to the remote destination.
The abstractions IDRP provides are comforting in the face of an
expanding internet. This abstraction of data will lessen the
routing information that is passed around. Less bandwidth
devoted to routing means there is more bandwidth for the
internet's real purpose- sending data from here to there.
"Hiding" by Use of OSI NSAP Structure
--------------------------------------
Network reachability information can be abstracted or hidden by
using the hierarchical nature of the NSAP address to group NSAPs
under shorter NSAP prefixes. Such prefixes are carried in IDRP
routes. Figure 6 shows an example of how several addresses are
combined into a shorter prefix. A part of an NSAP address used
to describe a group of NSAP addresses is called an NSAP Prefix.
Figure 6 - Combination of NSAPs into a Prefix
47.0005.80.ffff00.0000.0001.0001.010203040506.01
47.0005.80.ffff00.0000.0001.0002.80ff32401f23.01
47.0005.80.ffff00.0000.0001.0003.800103040500.01
could be represented by one of the following prefixes, among
others (going from most specific to most general).
47.0005.80.ffff00.0000.0001 or 47.0005.80.ffff00 or 47.0005 or 47
Sets of RDs Compress RD Pathway (Topology) Information
-------------------------------------------------------
In combination with the use of NSAP prefixes, RD path information
can abstracted from an ordered sequence of RDIs to an unordered
set of RDIs. Although some information is lost, the automatic
loop suppression mechanism in IDRP is preserved. For example,
if paths to two destinations have RD paths A,B,C and A,B,D, the
single unordered set A,B,C,D could be used and a single path
created. This abstraction may allow multiple routes to be
aggregated based on the policies of a routing domain.
RDCs allow Compression of Pathway Information and Policy
--------------------------------------------------------
Topology information can be abstracted using the IDRP concept of
Routing Domain Confederations. RDCs provide a nice means for
scaling. Fewer policies need to be administered by other routing
domains. Fewer total routes need to be reported to the world
outside the RDC. Inside an RDC the policies are exploded to serve
the needs of RDs within the Confederation. The IDRP protocol can
distinguish between intra-RDC and trans-RDC routing information.
In addition, transit policies may be implemented in the presence
of an RDC via the "Hierarchical Recording" feature.
Transit policies can also be abstracted by using RDCs. RDCs can
9
be nested, allowing policy for several routing domains to be
summarized as a single policy of a Routing Confederation.
Taming the Shrew -Reducing the Information Flow in Policy Routing
-----------------------------------------------------------------
In the play by William Shakespeare, "Taming of the Shrew," a
husband seeks to tame a head-strong wife. The wife has a strong
verbal flow and a stronger temper. He accomplishes this task by
taming himself and the wife. The wife learns that ranting and
raving can be more effective if it is truthful, used sparingly,
and directed at the right person.
RFC 1104 describes the same sort of global taming for the
Internet. The Internet, like the wife, has a strong flow of
information which must be tamed by correct policies in order to
let packets peacefully flow. Routes, like "ranting and raving,"
must be directed at just the right routing domains.
IDRP provides a taming or reduction of routing information and
processing via control of the distribution of information. Only
the actual routes that are selected to be used by a BIS are
propagated to other routing domains. Like what "truth in
advertising" should be for home appliances, the BIS only
advertises what it uses. We should have the same restriction on
those people who sell vacuum cleaners or coffee makers.
Each RD may also select the set of RDs to which its routes are
distributed. In this way, transit routing policies are supported
via control of the distribution of routing information. Again,
to use the analogy of home appliances, a company could choose to
not ship chain saws to someone under 16 years of age. Route
selection processing is also reduced because routes are selected
based on routes received (actual routes only) plus the local
BIS's policy, which can further reduce the number of routes.
The IDRP attributes "DIST_LIST_INCL" and "DIST_LIST_EXCL" give
routing domains the means to select the routing domains that will
receive their routing information. The "DIST_LIST_INCL" allows
routing information to be sent to RDIs listed in the attribute.
"DIST_LIST_EXCL" allows routing information to be sent to any RDI
not included in the attribute list. An RDI in one of these
attributes can specify either a routing domain or a routing
domain confederation.
The use Routing Domain confederation (RDCs) also helps tame the
flow of routing information needed. The "Hierarchical Recording"
attribute helps track when RDCs have been entered and exited so
routes can limited to within an RDC. Once a RDC has been entered
and the "Hierarchical Recording" attribute is set, routes can be
advertised only to BISs that can be reached without exiting any
RDCs. An RDC can be nested within an RDC or overlap another RDC.
Routes can be announced to RDs:
- within the same RDC,
- in an RDC nested in side this RDC, or
- or in an overlapping RDC.
This establishes a Hierarchy of RDs as you enter further into
nested or overlapping RDCs and controls route transitivity.
10
Disjoint RDCs are RDCs which can only be reached by exiting all
routing confederations in which this local BIS resides. The
"Hierarchical Recording" attribute cannot be passed between two
Disjoint RDCs.
Interaction with Intra-Domain routing
-------------------------------------
IDRP may need to interact with intra-domain routing if it is
running in an RD that contains end systems. First of all, IDRP
needs to know the set of NSAP prefixes reachable within the local
routing domain. This information is likely to be statically
configured information, and not extracted dynamically from
intra-domain routing.
Secondly, a representation of the destinations reachable outside
of the RD may be injected into intra-domain routing so that the
appropriate exit BIS can be reached. This information may be
provided to intra-domain routing in a dynamic fashion.
Both of these interactions can be accomplished by the
manipulation of managed objects via network management
primitives.
Reliability built into IDRP
---------------------------
Like the truck ads that say "Ford tough", the IDRP protocol is
built to be "internet tough". All communications between peer
BISs can be protected through the use of a cryptographic
signature on a per-packet basis.
Unlike BGP, IDRP implements its own reliable transport. Each
data-carrying packet (BIS protocol data unit (PDU)) contains a
sequence number which is used for re-transmission and flow
control. Data-carrying PDUs are the OPEN PDU (which contains the
connection information), the UPDATE PDU (which contains
incremental routing information), and the RIB REFRESH PDU (which
contains routing information). A retransmission timer controls
the retransmission of packets. The method of flow control is a
window scheme. This scheme only allows a fixed number of BIS
PDUs to be transmitted to a remote BIS neighbor prior to the
local BIS receiving an acknowledgement.
Especially Neat Features of IDRP
--------------------------------
Thanks to the rich technical environment of the Internet, the
contributors to the IDRP specification have put in several neat
features to make it work even better than BGP. Two of these
features which have made it into the current CD ballot version of
the document are:
1.) A BIS playing route server for another router
2.) RIB Refresh PDU
Some features which are under discussion but not in the CD ballot
are: Auto-configuration of BISs and Source-based routes.
11
The Route server function in IDRP allows one BIS to do policy and
handle the BIS PDUS but point to another router to do the packet
switching. Suppose your BIS was running on a slow packet pusher
(perhaps a unix system running "gated"). With the route server
you can point your data flow to a fast packet pusher of a router
(say one of the commercially available routers) and traffic would
not be impacted by the IDRP protocol running on a slow machine.
(figure 7 - Route Server. Figure 7 is only available in
postscript. The figure is available for anonymous ftp
from merit.edu in the directory /pub/iso/noop/tutorial
the file is idrp.f07.ps)
By using a RIB REFRESH PDU, a BIS may refresh its Routing
Information Base (RIB) from a neighbor BIS or to send its active
routing information to a neighbor BIS. If a router detects that
its routing information has been corrupted, it can get fresh IDRP
routing information from all its neighbors. Or perhaps something
convinces the BIS (or the person operating the router) that a
neighbor BIS has scrambled the routing information advertised by
the local BIS. The local BIS simply ships the remote BIS a new
copy of the RIB.
Auto-configuration of BISs involve the methods by which BISs can
communicate with each other without having to pre-configure each
neighbor BIS. This feature could make it easier to add new BISs
to an RD without having to reconfigure all other BISs.
Each network packet (NPDU) has a source and destination field
just like a good old IP packet. Source-based routing establishes
routes based on both source and destination addresses.
Source-based routing may help "commercial" traffic take a
different route than "research" traffic or provide two different
routes to the same destination, each tagged for a different set
of source addresses.
Conclusion
-----------
IDRP reminds one of "Stone soup". "Stone soup" is described in a
children's fairy tale in which three soldiers return from a war
and no one in the village wants to give them any food. They
start with 3 stones in a pot of water. By the end of the tale,
the villagers have added all the vegetables, meat and potatoes
you could ever want.
IDRP started with the concepts of BGP and the OSI routing
framework. These two original concepts are like the "stones" in
the "stone soup." To this beginning, the experience and needs
of the Internet community and the ANSI X3S3.3 communities have
been added to make IDRP one OSI protocol full of "meat" and
substance.
IDRP has already followed the tradition of Internet protocols by
having a prototype developed by Merit during the CD ballot stage.
Nothing improves a protocol like an implementor. Often
implementors cannot wait until they "talk" to the person that
12
wrote a protocol specification. This dialogue is most painful
when you are both implementor and the person that helped with the
original text.
Perhaps this tutorial has given you an appetite to read the
protocol and any associated documents. Below you will find a
reading list to help you fill up on OSI routing issues. Bon
appetit!
References
[1] "Information processing systems - Telecommunications and
information exchange between systems - OSI Routeing
Framework" (ISO TR 9575)
[2] "RFC 1136 - Administrative Domains and Routing Domains: A
Model for Routing in the Internet" (Hares/Katz)
[3] "Information processing systems - Telecommunications
and information exchange between systems - Protocol
for Providing the Connectionless-Mode Network Service"
(ISO 8473) March 1987
[4] "Information processing systems - Telecommunications and
information exchange between systems - End System to
Intermediate system routeing exchange protocol for use
in conjunction with the Protocol for providing
connectionless-mode network service (ISO 8473)"
(ISO 9542) March 1988
[5] "Information processing systems - Telecommunications and
information exchange between systems - Intermediate
system to Intermediate System Intra-Domain Routeing
Exchange protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode
Network Service (ISO 8473)", ISO 10589, forthcoming
Reading List
---------------
RFC 1136
RFC 1237
RFC 1195
Tutorials on the ISO routing documents [3], [4], [5],
found on merit.edu in the /pub/iso/noop/tutorial.
The actual ISO documents [1], [3], [4], [5], and IDRP.
Working copies of IS-IS, and IDRP can be found on
merit.edu for ANSI X3S3.3 committee work in the
/pub/iso directory.
ANSI X3S3.3 notes and mail archives on IDRP. The ANSI
X3S3.3 archives are on merit.edu. The ANSI X3S3.3 mail
list is x3s33@merit.edu.
13